A connection in a connection-oriented communication network follows a path. The connection has associated traffic parameters, referred to as traffic descriptor information including information such as allocated bandwidth. These are normally fixed for the duration of a call. However, there are some circumstances in which the user of the connection may wish to change the traffic parameters without disconnecting the call, in order to leave service unaffected. For example, services are envisioned in which a user may wish to increase bandwidth temporarily in order to download a large file while browsing the Internet, or may wish to increase bandwidth temporarily while playing an on-line game, without having to interrupt service by disconnecting and reconnecting the call with new traffic parameters.
Active Connection Modify (ACM) actions permit such modifications to the traffic parameters of an existing connection. A user initiates an ACM, which is received as an ACM request by the source node of the connection. The source node then attempts the ACM request using the signaling mechanisms defined in ITU-T Recommendations Q.2963.1, Q.2963.2, and Q.2963.3, each of which is referred to in ATM specification af-cs-0148.000, “Modification of Traffic Descriptor for an Active Connection, Addendum to UNI 4.0/PNNI 1.0/AINI”, The ATM Forum Technical Committee, July 2000.
When a source node receives an ACM request from a user, the source node starts a T360 timer, reserves resources associated with the ACM request, and sends a MODIFY REQUEST message (MOD REQ) to the next node along the connection. If the next node can accommodate the ACM request (for example, has sufficient available bandwidth to accommodate a bandwidth increase requested by the user), the resources for the MOD REQ are reserved and the node passes the MOD REQ on to the next node. This continues until the destination node receives the MOD REQ. If the destination node can accommodate the ACM request, the destination node implements the ACM request and passes a MODIFY ACKNOWLEDGE message (MOD ACK) to the preceding node. Each node in the connection that receives the MOD ACK implements the connection modification by allowing data to be transmitted at the new traffic parameter values (resources for which having been reserved upon receipt of the MOD REQ), and forwards the MOD ACK to its preceding node, until finally the source node receives the MOD ACK and implements the ACM request.
However, a node that receives a MOD REQ may not be able to implement the ACM request. For example, the node may have no additional unused bandwidth available on the connection to reserve for the connection. If a node cannot implement the ACM request, the node sends a MODIFY REJECT message (MOD REJ) back to the preceding node. The MOD REJ is forwarded back along the connection until it reaches the source node. When the source node receives the MOD REJ, the ACM request is therefore not implemented, the traffic parameters of the connection remain unchanged, and the user is notified that the ACM failed.
Some nodes may also generate a RELEASE in response to a MOD ACK being propagated back along the connection from the destination node to the source node, although there is a low probability of this happening since nodes should be reserving sufficient and correct resources during propagation of the MOD REQ. For example, resources that were available to accommodate the ACM request while the MOD REQ was being passed forward along the connection may no longer be available when the MOD ACK is received on its way back to the source node. In such a case the node at which there are no longer sufficient resources to implement the connection modification sends a RELEASE message in each direction, towards the source node and towards the destination node, and the call is released.
Any of the MOD REQ, the MOD ACK, and the MOD REJ may be lost due to congestion in the control plane, as described in af-cs-0181.000, “Signaling Congestion Control, Version 1.0”, The ATM Forum Technical Committee, April 2002. A MOD REQ may also be lost if a node along the connection does not support ACM. In either case, since the source node does not receive a MOD ACK or a MOD REJ the timer started by the source node will eventually expire. If the timer at the source node expires, the source node tears down the existing connection by sending a RELEASE message. The connection is torn down because the lack of receipt of a MOD ACK or a MOD REJ means that the source node does not know what has happened at other nodes along the connection. For example, some nodes may have increased the bandwidth allocated to the connection. After the existing connection is torn down a new connection may be established by the source node, but this re-establishment of the connection is not hitless in that there is a noticeable delay to the user and an interruption of traffic and service. A “hitless” switch to a new connection is usually defined as occurring within 50 ms.
One problem with the ACM signaling described above is that a user who makes an ACM request in which one of the ACM messages (MOD REQ, MOD ACK, or MOD REJ) gets lost due to congestion in the control plane may prefer that traffic on the connection remain unaffected. Given the current behaviors outlined in the procedures for ACM, a user cannot be provided with unaffected traffic during a connection modification. It would be desirable for such users to be able to maintain the connection or some variant thereof at the original traffic parameters even if the ACM request (and related messages) are lost, rather than suffering a noticeable data hit when rerouting to a new connection on a failure. This is particularly worrisome for Soft Permanent Virtual Circuits that are expected to never go down and to never lose traffic.
A second problem with the ACM signaling described above is that ACM requests may not be possible in a large number of currently deployed networks. Some carriers arrange connections on links so as to pack each link in turn before assigning new connections to a parallel link between the same two nodes. An ACM request for additional bandwidth for a connection along a packed link will likely result in an MOD REJ, since there is little or no additional bandwidth along the connection to allocate as new resources to the connection. There may be plenty of traffic resources available on a parallel link which could accommodate the user's ACM request, but these resources are not accessible given the current ACM behaviors.
A method of implementing ACM which minimized the likelihood of ACM rejections and which minimized the likelihood of releasing connections during an ACM request would provide improved ACM service.